With the emergence of 3G mobile telephony, new packet-based communication technologies using IP (Internet Protocol) have been developed to support wireless communication of multimedia. For example, communication protocols in GPRS (General Packet Radio Service) and WCDMA (Wideband Code Division Multiple Access) support packet-switched multimedia services, as well as traditional circuit-switched voice calls. New services are also constantly developed for both mobile and fixed users to increase the field of usage for their communication devices. It is also very useful to understand the needs and interests of users in different environments in order to create and offer services that are relevant and potentially interesting for the users in the prevailing circumstances.
A service and service-delivery control architecture called “IP Multimedia Subsystem” (IMS) has been developed by the 3rd Generation Partnership Project (3GPP) as a platform for handling multimedia services and sessions in the packet domain, based on IP transport. Thus, an IMS network can be used to initiate and control multimedia sessions for any fixed or mobile IP enabled terminals connected to any type of access networks.
Invoked multimedia services are enabled and executed by various application servers, either servers within the IMS network or external servers controlled by “third party” service providers. The sessions are controlled by various session managing nodes in the IMS network, and a database element HSS (Home Subscriber Server) stores subscriber and authentication data for subscribing clients. IMS is mentioned in this description for illustrative purposes only, although the present invention is not limited to using an IMS network. The advent of IMS has greatly fuelled the development of multimedia-based services.
Among other things, presence services have been introduced involving the publishing of presence data of clients to become available to other clients and applications. Presence data may indicate the behaviour of a client in some respect by basically defining the state or situation of the client and his/her equipment, commonly referred to as “device”. The presence data or client state may include a client status, a device status, the geographic location, device capabilities, and other personal client information such as interests, occupations, personal characteristics, moods, etc.
Recently, a concept has also been developed to provide refined or adapted information on communication clients, e.g. to increase the usability of applications for invoked services depending on the client's current situation or behaviour. This concept is generally referred to as the distribution of “context” information, which may be implemented by using similar mechanisms as for the above-described presence services. It is desirable to develop “context-aware” applications to achieve services optimally adapted to the prevailing circumstances. The context information reflecting the client's situation can thus be shared in client groups in the same manner as presence data, or be used to create an optimal service.
A context server may be used to collect information on the client by receiving client data from various sources, such as “sensors” or the like adapted to measure or register various variables or the like characterising the current state, status or situation of the client. For example, sensors may be arranged to measure physical characteristics such as temperature and movements, or to register device activities or any of the client states mentioned above for presence services. Hence, the above-described context information and the presence data of a client actually reflect the behaviour of that client in some respect, e.g. in terms of device usage and geographic whereabouts.
The currently available mechanisms for providing presence data and context data for a client of interest to a requesting party are illustrated schematically in FIG. 1. The client of interest 100 is a user of a mobile terminal T, or a software agent implemented therein, for which various event publications are sent to a presence server 102, either from the terminal itself or from the communication network used, as described above. The presence server 102 may in turn send notifications to the requesting party 104, e.g. a subscribing client, regarding current presence data.
In addition or alternatively, one or more sensors 106 may be arranged as described above to provide raw context data to a context server 108, the data being received and stored in a context storage unit 108a. The shown sensors 106 may also represent functions reflecting client activities in the terminal T or in the used network, not shown. Moreover, existing routines in the communication network for, e.g., generating call data records for clients can also be used to provide context data.
The stored raw data may then be processed and refined in a context refiner 108b by applying predefined rules 108c on the raw data, in order to derive or calculate new refined context information from the raw data. The predefined rules 108c may include algorithms or the like that calculate certain parameters, draw conclusions or create compilations from the raw data.
The refined context can then be distributed to the requesting party 104 according to conventional routines, not described here further. A policy for controlling the context distribution may also have been defined basically by the “context owner”, who may be a network operator or the client 100 himself/herself. The policy may dictate the extent of availability of the context data to requesters, or that a particular requester is allowed to receive only some part of the available context data, etc. It should be noted that the requesting party 104 may obtain a subscription to receive context information from the context server 108 on a more or less continuous basis, i.e. in a similar manner as for the presence data.
Typically, the context information pertains to an individual client who has a certain profile as defined by his/her current context. However, a client may also belong to an established group of clients, having an aggregate profile shared by its members. For example, members of a family group may have individual contexts while the family may have a common context with an aggregate profile shared by its members, whereas another group specifically interested in, e.g., football games may have a completely different profile.
WO 06/115442 discloses a mechanism where the particular needs of a requesting group of clients can be met by providing relevant context information regarding a specific object of interest, which information has been adapted to particular requirements and needs of the group. In this solution, a “customised” rule can be created for the requesting group defining conditions when requesting for refined context information. An aggregated context function creates an aggregated context for the group by collecting individual context data for each of the group's members, in order to create the customised rule valid for the group. The customised rule is sent to a context server (which may be configured basically as the context server 108 in FIG. 1) as an adapted request for refined context information on the object of interest. The context server then refines raw context data according to the customised rule and delivers the refined context data in response to the request.
It is thus common to form groups with plural members having mutual interests in some respect, in order to share information between the members by using any of the above-described mechanisms for presence services and client contexts.
When service providers offer various services to individual clients and groups of clients, e.g. by means of advertising, the services have typically been created on a more or less fixed basis requiring a certain amount of time and effort. In that case, the service and its parameters can be adapted to relatively static factors only due to the time it takes before it can be offered to clients. The service parameters therefore remain mostly unchanged throughout the lifetime of the service. Further, the clients have no possibilities to influence the character or nature of the services and must be content to select from the available services as they are offered by the service providers. The process of creating and configuring a service is often referred to as “service provisioning”, which term will be used in the following.
As mentioned above, mechanisms have been developed for context-aware services that can be adapted to the environment and/or the client's current situation or behaviour, e.g. in a request-triggered manner as described in afore-mentioned WO 06/115442. For example, a particular offered service can be configured differently depending on whether the clients are located in a quiet village in daytime or in a bustling city centre at night. Thus, the service parameters may vary during the lifetime of such context-aware services.
However, it is not always possible to determine or detect the specific needs or interests of individual clients or groups of clients in particular prevailing circumstances, even if great amounts of sensor information are available. The services that are offered may therefore be of limited relevance and interest for some clients in some situations.